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ervice  requirements  and  their  associ- 
;d  contracts  account  for  more  than 
ilf  of  the  Defense  Department's  an¬ 
nual  contract  spending.  A  clearly  writ¬ 
ten  requirement  is  the  key  to  meeting 
>ur  customers'  performance  needs. 


Contracting  officers  know  that  the  best  contract  in  the  world  cannot  save  poorly  defined 
requirements.  The  opportunity  for  protest,  claims,  cost  increases,  and  administrative 
nightmares  all  await  those  who  can't  define  the  results  they  need  from  their  service  con¬ 
tracts.  Reports  from  the  Government  Accountability  Office,  the  Defense  Science  Board, 
and  Inspector  General  routinely  identify  poorly  defined  requirements  as  a  common  fault 
in  services  acquisition.  So  how  can  we  define  better  requirements? 


The  Defense  Acquisition  University  (DAU)  has  developed  a  job  aids  and  training  process 
to  support  the  service  requirements  definition  process.  The  Acquisition  or  Automated 
Requirements  Roadmap  Tool  (ARRT)  is  a  Better  Buying  Power  job  aid  designed  to  help 
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users  improve  service  acquisitions  by  developing  high-quality 
performance-based  service  requirements.  ARRT  is  used  in 
conjunction  with  the  seven-step  service  acquisition  process 
outlined  in  the  DoD  Guidebook  for  the  Acquisition  of  Services 
(July  2011).  (www.acq.osd.mil/dpap/cpic/cp/docs/Guide- 
book_for_the_Acquisition_of_Services_7_20_2011.pdf) 

The  most  important  part  of  this  process  is  writing  the  require¬ 
ment  clearly  and  accurately.  Requirements  don't  exist  in  a 
vacuum;  there  must  be  a  sustaining  mission  need  within  an 
agency  or  organization  for  the  service  being  acquired.  The 
Performance  Work  Statement  (PWS)  must  capture  all  the 
performance  requirements  necessary  to  meet  the  agency's 
or  activity's  need  for  the  service.  This  requires  a  thoughtful, 
disciplined  approach  and  not  merely  a  cut-and-paste  from  the 
last  effort.  Your  results  can  be  improved  by  allowing  enough 


have  with  your  customers,  industry,  contracting  community, 
and  stakeholders. 

As  with  all  communications,  the  clearer  you  are,  the  fewer 
opportunities  there  are  for  misunderstanding.  Clearly  stated 
performance  requirements  will  result  in  more  competition, 
better  pricing,  and  a  greater  likelihood  you  will  get  the  results 
you  need  at  a  price  you  can  afford.  An  added  benefit  is  that 
the  resulting  contract  also  should  be  easier  to  administer  and 
the  contractor's  performance  easier  to  assess.  So  getting  the 
requirement  right  is  the  critical  part  of  this  process. 

The  Process 

Developing  a  performance  requirement  is  like  building  an  or¬ 
ganizational  chart.  In  the  case  of  service  requirements,  we  call 
it  a  work  breakdown  structure  or  WBS.  Figure  2  illustrates  a 


Figure  1.  Services  Seven-Step  Acquisition  Process 


Execute 


6.  Execute  Strategy 

•  Select  Right  Contractor 

•  Award  Contract 

•  Roll  Out  Strategy 


5.  Acquisition  Strategy 

•  Business  Strategy 

•  Source  Selection  Strategy 


Develop 


time  for  customers'  and  stakeholders'  input  as  well  as  building 
a  solid  acquisition  team  supporting  the  development,  execu¬ 
tion,  and  assessment  of  this  requirement  through  the  service 
acquisition  life  cycle. 

Requirements  for  services  are  sometimes  hard  to  define  or 
articulate.  You  can  see  and  understand  the  need  for  the  ser¬ 
vices,  but  how  do  you  describe  them?  Your  requirements 
document  is  the  most  effective  communication  medium  you 


PWS  WBS.  A  WBS  can  go  down  many  levels,  based  on  the 
nature  of  the  requirement.  It  is  important  when  developing  any 
requirement  to  provide  sufficient  detail  so  potential  contrac¬ 
tors  understand  the  results  you  need  without  telling  them  how 
to  do  it.  So  focus  on  results.  The  highest  level  of  your  WBS  is 
your  vision. 

In  Step  One  of  the  service  acquisition  process,  the  acquisition 
team  develops  a  vision  statement  for  the  requirement.  The 
vision  statement  is  a  guiding  goal.  It  should  capture,  at  the 
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Figure  2.  Work  Breakdown  Structure 


WBS  Level  1:  Vision 


WBS  Level 
High  Level 
Objectives 

WBS  Level 
Tasks 


highest  level  what  you're  striving  to  accomplish.  The  vision  is 
not  to  develop  a  PWS  or  issue  a  contract  or  obtain  27  support 
engineers.  Your  vision  and  mission  statement  go  together  to 
set  the  cornerstone  for  the  services  you  are  buying  and  why 
they  are  important.  At  one  time,  a  prominent  U.S.  airline's  vi¬ 
sion  statement  was  to  "move  people,  move  cargo,  on  time, 
every  time.''  If  you've  ever  flown  on  that  carrier,  it  did  a  pretty 
good  job  of  achieving  that  vision  because  all  its  actions  focused 
on  the  four  elements  of  the  airline's  vision  statement. 


If  using  a  SOO  is  not  appro¬ 
priate,  once  you  have  defined 
your  HLOs  you  can  begin  an 
analysis  of  the  tasks  or  re¬ 
sults  needed  to  support  each 
HLO.  This  is  WBS  Level  3. 
The  requirements  roadmap 
organizes  your  work  in  a  step- 
by-step  process.  The  ARRT 
captures  this  information  in  a 
database  by  asking  the  user  a 
sequence  of  questions  (A-H) 
that  walks  you  through  the 
necessary  thought  process 
for  documenting  your  require¬ 
ment.  Note  that  the  roadmap 
includes  not  only  the  perfor¬ 
mance  elements  of  task,  stan¬ 
dards,  and  Acceptable  Quality 
Level  (AQL)  but  also  the  in¬ 
spection/assessment  elements  of  monitoring  performance 
(the  Quality  Assurance  Surveillance  Plan  [QASP]  portion). 
The  reasoning  is  that,  as  you're  defining  the  performance 
results  and  standards,  you're  in  the  best  position  to  define 
how  each  task  should  be  inspected  and/or  assessed.  This 
ensures  alignment  of  the  requirement  with  the  inspection/ 
assessment  approach.  It  also  helps  in  developing  tasks  with 
inspectable  standards. 


For  example,  if  your  requirement  is  to  support  an  installation's 
transportation  needs,  your  vision  statement  might  be  some¬ 
thing  like  this:  "Ensure  our  installation's  mission  success  by 
providing  reliable  and  effective  transportation  support  24/7." 
Do  you  see  how  this  vision  statement  focuses  on  the  higher 
order  results,  not  just  on  the  transportation  function— in  other 
words,  how  the  transportation  function  will  be  an  enabler  for 
the  broader  organization's  mission  success? 

High-Level  Objectives 

After  you  have  developed  your  vision,  define  the  High-Level 
Objectives  or  HLOs  necessary  to  achieve  this  vision.  For  this 
example,  the  HLOs  could  be:  Transport  People,  Transport 
Cargo,  Fleet  Maintenance,  and  Fleet  Administration.  This  is 
WBS  Level  2.  HLOs  are  the  organizing  components  for  your 
requirement.  An  alternative  to  consider  at  this  point  is  whether 
to  use  a  Statement  Of  Objective  (SOO)  or  continue  to  develop 
the  PWS. 

A  SOO  gives  the  widest  possible  latitude  to  the  contractor  in 
developing  a  comprehensive  solution  for  your  requirement. 
Developing  broad  performance  outcomes  and  standards  for 
your  HLOs  provides  the  foundation  for  the  SOO.  In  their  pro¬ 
posals,  contractors  will  develop  the  tasks  and  standards  as 
they  create  a  PWS  that  captures  how  they  will  meet  your  H  LO 
performance  outcomes  and  standards.  Choose  the  approach 
best  suited  for  your  requirement. 


Performance  Tasks 

The  key  in  developing  good  task  statements  is  to  focus  on 
results.  Our  experience  has  shown  that  defining  results  seems 
to  be  one  of  the  hardest  concepts  to  grasp.  PWS  Task  State¬ 
ments  have  three  components; 

A.  The  result(s) 

B.  The  context  for  the  result(s) 

C.  The  actions  the  contractor  is  to  take  to  achieve  the 
results. 

Follow  this  A,  B,  C  process  and  you  have  the  elements  of  your 
PWS  Task  Statement.  The  ARRT  tool  will  automatically  take 
your  inputs  and  rearrange  them  (CAB)  to  form  a  clear  require¬ 
ments  statement  for  you. 

A  result  usually  is  a  noun,  describing  the  outcome  needed. 
Context  defines  what  the  results  apply  to.  Actions  describe 
what  the  contractor  has  to  perform  to  achieve  the  results  (nor¬ 
mally  verbs).  Let's  look  at  a  few  examples.  Can  you  find  the 
results,  context,  and  actions  required  in  these  statements? 

1.  The  contractor  shall  provide  and  maintain  taxi  service  within 
the  XX  installation. 

2.  The  contractor  shall  perform  and  document  initial  inspec¬ 
tions  for  newly  received  vehicles  and  equipment. 
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Use  as  many  standards  as 


necessary  to  fully  define  how  well 
the  task  must  be  accomplished 
to  meet  your  mission 
requirements.  Remember: 
Standards  are  cost 
drivers,  so  avoid  gold 
plating  standards,  as 


the  D  ques¬ 
tion:  At  what 
level  of  performance 
(standard)  do  you  need  to  suc¬ 
cessfully  achieve  this  task? 


this  will  drive  up  costs. 

3.  The  contractor  shall  evaluate,  participate,  and  prepare  Pro¬ 
gram  Management  Reviews  (PMRs),  technical  reviews,  and 
audits  for  the  transportation  office. 

A  PWS  task  statement  can  have  multiple  results,  but  remem¬ 
ber  that  all  the  results  listed  must  relate  to  each  other.  They 
must  also  share  the  same  actions,  context,  and  performance 
standards.  Try  to  limit  the  number  of  results  per  task  state¬ 
ment  to  those  that  are  truly  integrated  and  related  to  each 
other.  Create  as  many  task  statements  as  you  need  to  fully 
support  the  HLO. 

The  Service  Acquisition  Mall  (SAM)  website  includes  a  tool 
for  you  to  practice  this  ABC  process,  (http://sam.dau.mil/ 
skilldevelopmentcenter.aspx) 

Videos  also  are  available  in  SAM  that  will  provide  more  de¬ 
tailed  information  on  each  step  of  the  process  using  the  ARRT. 

Review  some  of  the  requirements  documents  you've  already 
created.  If  you  can  easily  find  the  results,  context  and  actions, 
you  probably  have  a  well-written  task  statement.  Each  task 
statement  requires  performance  standards  and  AQL  to  com¬ 
plete  a  PWS  task  statement.  Remember  that  the  requirement 
you  are  developing  is  a  communication  device,  both  to  industry 
and  to  the  COR.  It  should  communicate  clearly  and  accurately 
the  required  results  necessary  to  support  your  customer's  per¬ 
formance  need. 

Performance  Standards  and  Acceptable 
Quality  Level  (AQL) 

After  you've  defined  a  clear  PWS  task  statement  (steps  A,  B, 
C),  the  next  step  (D)  is  to  define  how  well  or  what  level  of  per¬ 
formance  is  required  for  this  task  to  adequately  meet  the  mis¬ 
sion  need.  Performance  standards  fall  into  one  of  three  catego¬ 
ries:  cost,  quality  (performance),  and  timeliness.  ARRT  asks 


Each  PWS  task  statement  may  have  several  different  perfor¬ 
mance  standards,  but  remember  that  each  standard  must  be 
related  to  the  actions  and  results  specified  by  the  task  state¬ 
ment.  For  example,  there  may  be  standards  such  as  regula¬ 
tions  or  technical  orders  compliance,  quality  or  frequency 
standards,  completion  or  timeliness  standards,  etc.  Use  as 
many  standards  as  necessary  to  fully  define  how  well  the  task 
must  be  accomplished  to  meet  your  mission  requirements. 
Remember:  Standards  are  cost  drivers,  so  avoid  gold-plating 
standards,  as  this  will  drive  up  costs. 

The  Acceptable  Quality  Level  (AQL)  recognizes  that  varia¬ 
tions  can  happen  and  that  100  percent  performance  is  not 
always  possible.  Use  good  judgment  in  determining  if  an  AQL 
is  appropriate.  For  example,  a  standard  for  on-installation  taxi 
service  is  to  pick  up  the  passenger  within  10  minutes  of  the 
call  being  received  by  the  contractor;  this  means  100  percent 
of  the  time.  Ask  yourself  if  it  is  absolutely  necessary  to  meet 
the  10-minute  standard  100  percent  of  the  time.  What  are  the 
risks  to  the  activity  if  the  10-minute  standard  is  not  met?  These 
are  questions  you  should  consider  when  determining  if  an  AQL 
is  advisable.  Using  your  risk  assessment  process  should  help 
in  determining  both  standards  and  AQLs.  In  this  case,  perhaps 
meeting  the  10-minute  standard  80  percent  of  the  time  is  ac¬ 
ceptable  performance.  Then  our  AQL  is  80  percent.  There  are 
many  instances  such  as  environment,  technical  orders,  laws, 
etc.,  where  100  percent  compliance  is  absolutely  essential. 
Conducting  a  good  risk  analysis  will  help  in  determining  if  and 
at  what  level  an  AQL  can  be  established. 

Performance  Inspection  and  Assessment 

Now  that  you've  defined  your  PWS  task  statement  (ABC), 
and  established  standards  for  it  (D),  you  need  to  capture  the 
elements  of  your  QASP  to  define  who  will  inspect  and  assess 
performance  and  how  this  will  be  done.  These  issues  are  ad¬ 
dressed  by  questions  E-G.  Question  E  focuses  on  what  you 
will  inspect.  This  should  be  directly  related  to  the  result  of 
your  task  statement.  If  the  "What"  is  a  deliverable  such  as  a 
report,  you  need  to  identify  it  as  a  data  deliverable,  capture 
a  description  of  it  and  tie  it  to  the  task  statement.  ARRT  ties 
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the  deliverable  to  the  task  and  also  automatically  creates  the 
Deliverables  Section  of  the  PWS.  After  looking  at  your  Task 
Statement,  if  you  can't  determine  "what"  you  will  look  at,  you 
should  go  back  and  work  on  the  task  statement  to  define  a 
result  that  can  be  inspected. 

Next,  Question  F  asks  "How  will  you  inspect  it?”  There  are 
several  methods  to  inspect  and  assess  a  task  such  as:  100  per¬ 
cent  inspection,  periodic  inspection,  random  sampling,  trend 
analysis,  customer  complaints,  and  third-party  audits.  Since 
you've  just  defined  the  task,  you're  in  a  good  position  to  specify 
how  you  intend  to  inspect  and  assess  performance  to  deter¬ 
mine  if  the  contractor  has  met  the  performance  standards. 
Remember  that  inspection  requires  resources.  You  should  ask 
yourself  whether  you  have  the  resources  necessary  to  inspect 
everything  that  will  be  necessary  for  your  requirement.  Your 
risk  analysis  will  be  very  valuable  in  helping  you  determine 
the  level  and  frequency  of  inspections  required  for  each  task. 

Question  G  asks:  "Who  is  going  to  inspect  this?"  This  respon¬ 
sibility  normally  falls  on  the  Contracting  Officer's  Represen¬ 
tative  (COR),  but  it  can  also  be  a  combination  of  a  technical 
expert  in  coordination  with  the  COR.  You  can  be  as  specific  as 
you  need  in  defining  the  position  responsible  for  conducting 
the  inspections.  This  should  be  a  position— not  necessarily  a 
person  by  name.  Before  contract  award,  you  must  identify  the 
person  responsible  for  inspecting  and  assessing  contractor 
performance.  Make  sure  that  person  completed  the  neces¬ 
sary  COR  training  and  is  technically  qualified  to  perform  the 
function.  Remember:  The  QASP  is  a  government-developed 
document  and  is  not  included  as  part  of  the  contract. 


must  be  included  in  the  contract  and  is  captured  in  the  Per¬ 
formance  Requirements  Summary  (PRS)  as  part  of  the  PWS. 
This  ensures  contractors  are  aware  when  they  submit  their 
proposals  of  any  remedies  that  may  be  required  of  them  for 
unsatisfactory  performance. 

Conclusion 

Following  a  standard  service-acquisition  process  to  define  and 
develop  requirements  has  the  potential  of  reducing  acquisi¬ 
tion  lead  times,  obtaining  better  competition,  reducing  costs, 
and  delivering  better  results.  The  ARRT  will  help  you  capture 
requirements  more  accurately  and  clearly.  ARRT  users  have 
reported  they  have  reduced  acquisition  lead  times,  received 
fewer  RFP  questions,  and  have  better  proposals  to  evaluate 
with  less  administrative  work  after  contract  award. 

With  the  budget  challenges  facing  the  Department  of  Defense, 
we  all  need  to  work  on  improving  the  effectiveness  and  ef¬ 
ficiency  of  the  service  acquisition  process  to  "deliver  more 
without  more." 

ARRT  is  a  free,  downloadable  MS  Access  file  that  guides  a 
user  through  a  disciplined  process  to  define  the  results,  stan¬ 
dards,  and  method  of  inspection  using  standard  templates 
for  the  Performance  Work  Statement  (PWS),  Quality  As¬ 
surance  Surveillance  Plan  (QASP),  and  the  Performance  Re¬ 
quirements  Summary  (PRS).  (http://sam.dau.mil/Content. 
aspx?currentContentlD=arrt)  & 

The  author  can  be  contacted  at  lyle.eesley@dau.mil. 


The  last  question  to  ask  is,  "Are  there  any  incentives/remedies 
beyond  documenting  past  performance  for  the  contractor  if 
it  exceeds/fails  to  meet  the  performance  standards  for  this 
task?”  This  is  Question  H  in  ARRT.  Capturing  and  document¬ 
ing  contractor  performance  is  a  requirement  for  all  govern¬ 
ment  contracts  and  is  reported  and  captured  in  our  past 
performance  system.  This  is  always  an  incentive  for  a 
contractor  to  do  well.  Question  H  gets  at  the  specif¬ 
ics  for  this  task  and  can  be  influenced  by  the  type  of 
contract  used  for  this  effort.  In  a  fixed-price 
contract,  the  contractor  has  agreed  to 
meet  all  the  performance  standards  for 
the  price  specified.  If  the  contractor's 
performance  fails  to  meet  the  stan¬ 
dard,  the  government  is  entitled  to 
a  remedy  such  as  having  the  con¬ 
tractor  redo  the  task  at  no  addi¬ 
tional  cost,  or  deducting  money 
from  the  contractor's  invoice  if 
re-performance  is  not  possible. 

If  a  cost-reimbursement  type 
contract  or  time-and-material 
contract  is  used,  be  careful  not 
to  pay  twice  for  the  same  service. 

The  incentive/remedy  information 


ARRT  users  have  reported  they 
have  reduced  acquisition  lead 
times,  received  fewer 
RFP  questions,  and 
have  better  proposals 
to  evaluate  with  less 
administrative  work 
after  contract 
award. 


55 


Defense  AT&L:  January-February  2013 


